Multi-user applications in multimedia networks

ABSTRACT

The invention provides a solution for alleviating problems related to operation and administration of multi-user application programs, particularly real-time applications, in systems of networked computers by means of a novel feature, implemented as an enhancement of a selected call control protocol, such as the H.323 or SIP protocol. Each client, server, Gatekeeper and optional firewall means of a system according to invention is provided with a specific real-time codec with a common interface adapted to a multimedia call control protocol, such as H.323 or SIP, the codec being adapted to co-operate with each of said means. Thus, for example, each of said client means is allowed to use its data communication protocol of choice without the need for the same data communication protocol choice on the server side of the application.

FIELD OF THE INVENTION

[0001] The invention relates to the field of multi-user applications insystems of networked computers, and more particular to a multi-usercomputer system, method and arrangement employing multimedia callcontrol, for alleviating problems of operation and administration ofmulti-user or real-time application programs in systems of networkedcomputers.

THE PROBLEM AREAS

[0002] In systems with networked computers, it is often desirable toallow more than one user to interact with a single application at thesame time (concurrently). Such applications are often called multi-userapplications. Each multi-user application can be said to belong to oneof the following two groups:

[0003] 1) Multi-user applications with real time requirements; and,

[0004] 2) Multi-user applications without real-time requirements.

[0005] Typical examples of applications that belong to the first groupare multimedia conferencing applications and multi-player games, whilemulti-user white boarding and word processors with document sharing aretypical examples of applications belonging to the second group.

[0006] When enabling more than one user to interact with the sameapplication, typically, the users are each provided with parts of theapplication, hereinafter referred to collectively as clients. Theclients then communicate with the remaining parts of the application,hereinafter referred to collectively as the server. The physicallocation of the server can be a computer shared with one of theparticipating clients, which typically is the case for word processorsharing and games, or it can be a separate computer such as a dedicatedserver computer. Use of a separate computer is quite common when theshared application needs more resources than what is available at thelocation of any of the clients.

[0007] A protocol is used for information exchange between the clientand the server. Although several standard protocols exist, customisedprotocols that are optimised for each type of application are commonlyemployed. The reason for this is that each type of application has itsown, specific needs. A typical shared real-time application will oftenmake use of small data packets to increase transfer speed, whilenon-real time applications will often make use of larger data packets todecrease the use of communication channel bandwidth for the informationexchange.

[0008] Network games can be, as mentioned earlier, typical examples ofmulti-user applications with real-time requirements. In network games,each client runs most of the application locally. This means that theclients send only information to the server about the positions in thegame and the current status of their respective players (the type ofinformation, sent and received, is of course dependent upon the type ofgame). The server then co-ordinates and combines the informationreceived from all clients and sends co-ordinated and combinedinformation back to the respective clients. If only a small number ofusers, say, less than ten, is supported, then the server is oftenlocated with one of the clients. If, on the other hand, a large numberof concurrent users are allowed, then the need for computer resourceswould be greater, and the server in such cases are often assignedseparate hardware.

[0009] When, in a networked system, each such multi-user application isusing its own protocol, this represents a significant problem to theadministrator of these protocols, as it is difficult, and sometimes evenimpossible, for the administrator to perform common administration ofthe supported multi-user applications. In this context, administrationis defined as:

[0010] Methods for access control of who is allowed to communicate withthe server

[0011] Trace logs of usage

[0012] Fault handling

[0013] Administration of addresses and users

[0014] All the needed logic to perform user billing of usage of theserver

[0015] Other types of administration

[0016] Yet another problem encountered in such situations is to enablethe different multi-user application protocols to pass through afirewall. This is especially difficult with multi-user applications withreal-time requirements, because such applications often use the UserDatagram Protocol (UDP) as a transport protocol. Due to theconnectionless nature of UDP, it is difficult to allow UDP based trafficto pass through a firewall and at the same time obtain good protectionby the firewall.

[0017] Another problem related to using one of the standard call controlprotocols for multi-user server communication is that the existing meansfor transporting information, hence not session initiation information,in current solutions are based on codecs that are optimised for voice,video or other non real-time data transfer. For transport of real-timedata, these codecs are not suitable.

[0018] Furthermore, it would be beneficial if all multi-userapplications that operate in one domain could use the same communicationprotocol. If they all make use of the same communication protocol,administration problems (e.g. access control, trace logs, etc.) andcommunication problems (e.g. enable communication through a firewall)could be solved for the common protocol, and hence be used by allmulti-user application servers.

KNOWN SOLUTIONS AND PROBLEMS WITH THESE

[0019] One suggested solution to the problem of administration is toimplement separate support for administration of each type ofapplication. The major problem with this method is, firstly, that foreach new supported multi-user application the administration has toimplement a new set of administration mechanisms, and secondly, that theadministrator has to integrate the new set of administration mechanismswith existing administration for other multi-user applications.

[0020] Another suggested solution to the same problem is to support onlymulti-user applications that use a standardised protocol such as forexample the Hyper-Text Transfer Protocol (HTTP). This, however, leads toother problems, as use of a single protocol will make it very difficultto make multi-user applications work in the network because of theirdifferent nature and their different resource requirements.

OBJECTS OF THE INVENTION

[0021] It is, therefore, an object of the invention to provide asolution to the problems outlined above, and which overcome the problemsof the known solutions.

BRIEF DISCLOSURE OF THE INVENTION

[0022] The present invention provides a system recited in theaccompanying independent claim 1, a method recited in the accompanyingindependent claims 2, 8, 9 and 10, and an arrangement recited in theaccompanying independent claim 7. Other advantageous features of theinvention are recited in the accompanying dependent claims 3-6 and11-14.

[0023] The present invention proposes a solution to solve the problem ofadministration of different multi-user applications by means of theH.323 standard according to ITU-T Recommendation H.323, 02/98“Packet-based multimedia communications system”, which is the standardmostly used for systems providing multi-media traffic today.Establishing and administrating connections between clients and theirrespective servers by means of H.323, according to the invention,provides the advantage of allowing a system that includes applicationspecific protocols as well as one common standard protocol, namely theH.323.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024]FIG. 1 is a block diagram representation of a simplified H.323network example, illustrating client registration and authorisation.

[0025]FIG. 2 is a block diagram representation of a simplified H.323network illustrating set-up of a H.323 client-to-server network call andextended functions.

[0026]FIG. 3 is a block diagram representation of a simplified H.323network illustrating client-server information exchange according to theinvention through a firewall.

[0027]FIG. 4 is a schematic representation of an embodiment of a userdata packet structure of the invention.

[0028]FIG. 5 is a schematic representation of an embodiment of a controldata packet structure of the invention.

[0029]FIG. 6 is a sequence diagram illustrating an example ofinformation exchange between server and client in an exemplaryembodiment of a solution according to the invention.

[0030]FIG. 7 is a sequence diagram illustrating an example ofinformation exchange between server and client in another exemplaryembodiment of a solution according to the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0031] In the following, the present invention will be described by wayof example and with reference to the accompanying drawings.

[0032] Referring to FIG. 1, when the client is started, it first uses aknown registration process of H.323 version 2 to be registered andauthorised in the network. It should also be noted that, in thesituation illustrated in FIG. 1, the server is already registered in theH.323 network. When using H.323, the client side of the application andthe server side of the application must both support the H.323 stack.Further, to have full service, the server must be running all the time.Through the registration process, the user is authorised (authorisationis new in version 2 of H.323). This means that the operator can decidewho is allowed to contact the server. Up to this point, conventions andinteractions in the network are according to the known steps of theH.323 version 2.

[0033] Now, referring to FIG. 2, when the client initiates a call withthe gaming server as the destination, the gatekeeper will check in theusers profile, which is received from a User Handling Database (UHD), tosee if the users is allowed to use the gaming server, denoted by GamingServer Info in FIG. 1. In order to fetch this data and to perform theevaluation, new functionality is added to a normal H.323 Gatekeeper. Ifthe user is found to be allowed to “call” the gaming server, then thegatekeeper informs the client that he is allowed to make the call set-upas is typically done according to H.323.

[0034] Then the client starts the data channel of H.323 towards theserver. This is allowed according to H.323, although it is not usuallydone this way as the procedure usually employed is to start voice andvideo channels. According to invention, the H.323 protocol is extendedto support a new codec. This is shown below:

[0035] For the purpose of simplifying the explanation of the solution ofthe invention by way of example, in the following, H.323 and H.323 namesand terms will be employed extensively. A new codec that is specialisedfor real-time data transfer has to be developed. In H.323 the new codechas to be identified in the ASN.1 syntax as described below:DataApplicationCapability ::=SEQUENCE { application CHOICE { nonStandardNonStandardParameter, t120 DataProtocolCapability, dsm-ccDataProtocolCapability, userData DataProtocolCapability, t84 SEQUENCE {t84Protocol DataProtocolCapability, t84Profile T84Profile }, t434DataProtocolCapability, h224 DataProtocolCapability, nlpid SEQUENCE {nlpidProtocol DataProtocolCapability, nlpidData OCTET STRING },dsvdControl NULL, h222DataPartitioning DataProtocolCapability, ...,t30fax DataProtocolCapability, t140 DataProtocolCapability A new codectype DataProtocolCapability }, maxBitRate INTEGER (0..4294967295), --units 100 bit/s ... }

[0036] This basis for the ASN.1 code shown above is described in ITU-TRecommendation H.245, 02/98 “Control protocol for multimediacommunication”. The code above, being an amended code applicable tosolutions according to H.245, shows how the Data Application field ofthe H.245 protocol is extended to accommodate the invention. In systemoperating according to the invention, such adaptation of H.245 isincluded in all clients, servers, and gatekeepers that has registeredgaming servers to them (if the gatekeeper is routing h.245). In thiscontext, the particular name of the new codec is not relevant, just thatit is a new one. Any requirements for more than one new codec in aparticular system will depend on the requirements defined for thecommunication between the client and the different types of gamingservers. What is important, though, is that a game server and all of itsconnected clients must provide support for the same codec type.

[0037] The new codec is designed in a simple fashion, meaning that itrequires little overhead. In the following, some of the characteristicsof the new codec are given:

[0038] The codec uses RTP (Real-time transport Protocol) over UDP (UserDatagram Protocol) to obtain real-time transport

[0039] The codec includes mainly to types of messages: a) a datamessage, and b) a control message.

[0040] The data message can be sent from the client or from the server.The control message is only sent from the server.

[0041] Referring to FIG. 4, an example of a data packet of the new codecwill now be explained:

[0042] In the Type field is an identifier defining the type of messageis (e.g. 1=data message, 2=control message); which in this case is adata message.

[0043] In the Protocol field is an identifier defining how the data inthe rest of the message shall be interpreted. Note that there has to bea common understanding of the data format among client and server.

[0044] In the Data field is included the data that is sent from theclient or from the server

[0045] Referring now to FIG. 5, an example of a control packet of thenew codec will be explained:

[0046] In the Type field is an identifier defining the type of messageis (e.g. 1=data message, 2=control message); which in this case is acontrol message.

[0047] In the Protocol field is an identifier defining how the Controlinformation in the rest of the message shall be interpreted. Note thatthere has to be a common understanding of the control format amongclient and server.

[0048] In the Data field is included the control information that issent from the server towards the clients. Examples of controlinformation are how often data messages shall be sent from the clienttowards the server, and how often the server will send data messagestowards the client.

[0049] Note that time-stamps and sequence numbers is not part of thecodec messages, because this information typically can be obtained fromthe RTP header.

[0050] Now, with reference to the accompanying FIGS. 6 and 7, and by wayof example, information exchange in a client-server configuration in anembodiment of the invention will be explained. The referenced FIGS. 6and 7 generally show examples of the communication sequence between aclient and a server. In the sequence examples shown, there are somecommon steps. The client initiates the communication by sending a“setup” message according to the standard call control protocol whichhas been selected; that is, generally, H.323 or SIP. Then the serversignals accept of the incoming “setup” by sending an accept messageaccording to the selected call control protocol. The call control partof the client then sends a suggested media set and address, includingthe new codec. Further, as shown in the examples, the suggested mediaset is accepted by the server by a message that also includes the mediadestination address to which the client is to send the media. At thispoint in the sequence, two different possibilities are available. Onepossibility is that the address is sent from the Call control towardsthe application part in both the server and the client, in which case itis the application on the client that sends the media using the newcodec directly towards the application on the server. This firstpossibility is illustrated by the further parts of the sequence shown inFIG. 6. The other possibility is that the Call control on both theserver and client sends a “start” message, or a similar kind ofinformation, indicating that communication is now established betweenthe server and the client. In this latter case, media sent in the newcodec is first transmitted from the application towards the Call controland then from the Call control on one side over to the other Callcontrol, and then on to the application. This other possibility isillustrated by the further parts of the sequence shown in FIG. 6. At thetermination of a session, the client send a “close” message. However,closing can also be initiated by the server. The entity receiving the“close” message informs the application that the session is over, andresponds to the “close” message by sending back an “accept” message.

[0051] Now, with reference to FIGS. 4, 5, 6 and 7, the message types andtheir use will be explained by way of example. In accordance with asequence as described above, the sever can first send a control messageincluding information specifying the rate at which data is to be be sentform the client to the server, and possibly also information about thedata type. In turn, the client sends data to the server at the specifiedrate and of the specified type, according to the scheme specified in thecontrol message. Such control messages can be sent at any time during asession, in order for the server to specify different data rates anddata types according to the needs of the application associated with thesession.

[0052] With reference to the sequences explained above, it should benoted that the different possibilities illustrated by FIGS. 6 and 7 alsocan be mixed or combined, in such a way that either the server party orthe client party follows one of the sequences, while the other partyfollows the other sequence.

[0053] In H.323 networks with gatekeepers, all signalling must gothrough the gatekeeper. When the gatekeeper allows set-up and operationof a call, it can, according to known H.323 architecture andimplementations, inform the normal charging system of that usage hasstarted. A charging system can be added to a system, such as the systemdepicted in FIG. 1, in a number of different ways. A simple andeffective way of accomplishing charging, is that the gatekeeper writesinformation related to call-setup and stop to an ASCII-file. A programcan process this file by manual or automatic means at a later stage intime. A more advanced solution is to send Call Detail Records (CDR) toan external system. CDRs can include information about call start time,call stop time, activity, resources used, etc. The external system canthen be made to automatically interpret these records and produce a costof use (charging) to the end-user directly.

[0054] Further, as illustrated in FIGS. 6 and 7, when seen inconjunction with the messages describe with reference to FIGS. 4 and 5,when establishing the data channel, the client informs the server ofwhich protocol to use for the data communication. For a system accordingto invention, this is to be the new codec as described above. This meansthat the applications themselves can use whichever protocol they desire,as long as it maps into the new codec type. During the H.323 set-upphase, both the client and the server also inform each other of ports onwhich they want to receive data, and of which transport protocol is tobe used, such as e.g. whether they use TCP (Transmission ControlProtocol) or UDP (User Datagram Protocol). This information can furtherbe used by a H.323 Proxy to enable the chosen data protocol to betransferred through a firewall, as illustrated in FIG. 3. If an H.323proxy is used, it also will be updated with the enhanced H.323 protocol.

[0055] Referring to FIG. 3, an example is shown, wherein two clientscommunicate with the server. They use both the H.323 protocol, which issent via the gatekeeper, and the chosen data protocol directly. When thedata channel is established, the client informs the server of whichprotocol to use for the data communication. This means that theapplications can use any preferred protocol. In FIG. 3 a firewall isalso shown together with a H.323 proxy. The reason for including theproxy functionality is two fold. Firstly, it is quite common to have afirewall at every enterprise and ISP to protect their respective areas.Secondly, NAT (Network Address Translation) is often used by enterprisesfor sharing one single IP-address, and for not giving away informationabout IP-address for nodes located inside the domain of the enterprise.H.323 does not include support for NAT and proxies in itself, but byusing the H.323 proxy, the IPT solution alleviates the limitations ofthe H.323 v2 standard related to communicating with endpoints locatedbehind firewalls.

[0056] In accordance with the above, the H.323 Proxy contains thefollowing functions:

[0057] The H.323 proxies the RAS signalling (registration andadmission), and replaces the internal IP addresses of the enterprise inthe RAS messages with public IP addresses (NAT-Network AddressTranslation).

[0058] The H.323 proxies the Q.931 signalling (call set-up), andreplaces the enterprise internal IP addresses in the Q.931 message withpublic IP addresses.

[0059] The H.323 proxies the H.245 signalling (media channel set-up),and replaces the enterprise internal IP address in the H.245 messageswith public IP addresses. If the endpoint uses H.245 in a separatechannel the H.323 proxy transforms this to a tunnelled H.245 since theIPT system always uses tunnelled H.245.

[0060] The H.323 proxy controls the media streams that are set-up as aresult of the H.245 signalling, and proxies the media streams (mediastream NAT).

[0061] From the example described above, and as illustrated by FIG. 3,it should be noted that the chosen data protocol can be sent through afirewall when using a H.323 proxy.

[0062] The procedure of authenticating H.323 end-user in H.323 systemsis specified in H.323. However, it is only specified how the user nameand password can be sent from an end-user to the gatekeeper. To obtaintrue authentication, a means for checking the username against thepassword must be added to the system. On way of allowing this check tobe accomplished is, as illustrated in the accompanying FIGS. 1, 2 and 3,to add a database to the gatekeeper. This database will at least includea record for each user containing a username and a password. Thegatekeeper will then check if the end-user exist in the database. If theend-user exists in the database, then the gatekeeper obtains thepassword of the user and checks to see if it matches the passwordreceived by the end-user. The database and its associated logic is inthis solution referred to as the User Handling. The data that determinesif the user is to be allowed to make a call can be added to the userrecord stored for each user in the database described above.

[0063] During the H.323 set-up phase, the client and the server alsoboth inform each other of on which ports they want to receive data andof whether they are using the Transmission Control Protocol (TCP) orUDP. This information can be used by a H.323 Proxy to enable the chosendata protocol to be transferred through a firewall.

[0064] When the set-up phase is over, the respective client and serveruse the chosen protocol that is optimised for their needs to transferdata to each other.

[0065] When the session is over, the client closes the connections andinforms the gatekeeper. The gatekeeper then informs the charging systemthat the usage of the server has stopped. If a client should becomeinoperable or a network failure should occur, then the system can alsodetect this because H.323 requires regular updates of the status of the“call”. A correct record of time of usage is therefore guaranteed.

[0066] Although only a simple H.323 network is shown in the FIGS. 1, 2and 3 to simplify the drawings for the purpose of explaining theinvention, the solution provided by the present invention will also workin large-scale H.323 networks or in networks having an architectureand/or operating according to similar call control protocols, such asfor example the SIP protocol.

ADVANTAGES

[0067] By using H.323, the applications can easily be integrated withvoice and video if they do not already have this support. This will givesome application a new dimension without the need for making largechanges the application required otherwise.

[0068] When using H.323, the client does not need to know theIP(Internet Protocol)-address of the server, as the H.323 supports moreadvanced address schemes like E-164 numbers, e-mail addresses oraliases.

ABBREVIATIONS, DEFINITIONS AND ACRONYMS

[0069] ANSI American National Standardisation Institute API ApplicationProgramming Interface ASCII American Standard Code for InformationInterchange ASN. 1 Abstract Syntax Notation Number 1 (a formal datastructure definition language) Codec Coder/Decoder E-164 A standardnumbering scheme ETSI European Telecommunication Standards Institute GKGatekeeper HTTP Hyper Text Transport Protocol IP Internet Protocol IPTInternet Telephony ISDN Integrated Services Digital Network ISP InternatService Provider ITU H.225.0 A subset of the H.323 standards suite beingbased on Q.931 and defining call control messages, encoding standardsand call-state sequences. ITU H.245 ITU-T Recommendation, “Controlprotocol for multimedia communication”, 02/98. ITU H.323 ITU-TRecommendation, “Packet-based multimedia communications system”, 02/98,specifies signalling and transport for multimedia traffic over a packetswitched network. (A family of ASN.1 encoded protocols defining messageformats, encoding standards and call state sequences of multimediaconferences on an Internet protocol infrastructure.) ITU H.450 A suiteof ASN.1 standards defining service control protocols to be used forservice control in an H.323 network. The H.450 messages are beingcarried within H.225.0 messages. ITU Q.931 Telephony standard for callcontrol that defines call control messages, encoding standards andcall-state sequences. ITU-T International Telecommunication Union -Telecommunications sector NAT Network Address Translation RASRegistration, Admission and Status RTP Real Time Protocol SIP “SIP,Session Initiation Protocol”, Internet Engineering Task Force, RFC 2543,March 1999, (Handley, M., Schulzrinne, H., Schooler B., Rosenberg J) TCPTransmission Control Protocol UDP User Datagram Protocol

Having described my invention, I claim:
 1. A system of computersnetworked by means of the H.323 protocol or the SIP protocol, each ofsaid systems including at least one Gatekeeper means and at least oneeach of server and client means for operating a client/server multi-usercomputer application, and, optionally, a firewall means provided withH.323 or SIP proxy, wherein client registration and authorisation in thenetwork are according to registration and authorisation method of H.323or SIP, characterised in a user handling database means associated withsaid Gatekeeper means, and that each of said Gatekeeper means, servermeans and client means comprises a real-time codec having a common H.323or SIP interface, each of said codecs being adapted to co-operate withthe respective Gatekeeper means, server means or client means.
 2. Amethod for alleviating problems of operation and administration ofmulti-user computer application programs in systems of computersnetworked by means of the H.323 OR SIP protocol, each of said systemsincluding at least one Gatekeeper and at least one each of server andclient for operating a client/server multi-user computer application,and, optionally, a firewall provided with H.323 or SIP proxy, saidmethod comprising the steps of client registration and authorisation inthe network are according to registration and authorisation method ofH.323 or SIP, characterised in that the method further comprises:initiating, by the client, a call set-up with the server as thedestination, thereby exchanging information of ports for receiving dataand of whether the communication protocol is TCP or UDP, checking, bythe Gatekeeper, in a user profile obtained from a user handling databaseassociated with said Gatekeeper to determined whether or not the clientis allowed to make a call set-up towards the server, informing, by theGatekeeper, the client of whether or not that the client is allowed tomake the call set-up, and starting, by the client, a data channeltowards the server according to an enhanced H.323 or SIP upon the callset-up for which the client is allowed to make, which enhanced H.323 orSIP is enhanced by an extension supporting a specific codec and isoperable on the client and the server, said codec is arranged to bemapped into by a protocol employed by the client and by a protocolemployed by the server.
 3. A method according to claim 2, characterisedin that the method further comprises: transferring, by the client andupon call set-up, data from the client to the server, and vice versa, bymeans of a selected protocol mapping into the real-time codec.
 4. Amethod according to claim 2, characterised in that the method furthercomprises: closing, the client and when the session established by thecall set-up is over, connections between the client and the server, andinforming the gatekeeper according to corresponding methods of H.323 orSIP.
 5. A method according to claim 2, characterised in that the clientis a game client and the server is a game server.
 6. A method accordingto claim 2, characterised in that the method further comprises:monitoring , by the gatekeeper, the status of the call set up betweenthe client and the server, and maintaining a record of the duration ofthe call.
 7. An arrangement for operation and administration ofmulti-user computer application programs in systems of computersnetworked by means of the H.323 or SIP protocol, each of said systemsincluding at least one Gatekeeper and at least one each of server andclient for operating a client/server multi-user computer application,and, optionally, a firewall provided with H.323 or SIP proxy, whereinclient registration and authorisation in the network are performedaccording to registration and authorisation method of H.323 or SIP,characterised in that each gatekeeper, client, server and optionalfirewall element of the system is provided with a co-operating H.323 orSIP protocol enhancement function means comprising a specific real-timecodec being adapted to co-operate with a respective Gatekeeper, client,server or optional firewall element.
 8. Method of using of a H.323 orSIP telecommunication network arrangement in a computer network gamesystem including a plurality of computer network game clients and atleast one respective computer network game server, said serveroptionally being protected by a computer network firewall, characterisedin that the method comprises: controlling a clients access to theserver, allowing, optionally, undisturbed data communication through thefirewall between a server and a respective client, obtaining data for aclients usage of the server, the data being useful for usage charging,and handling and recording communication faults and irregularities.
 9. Amethod of providing co-operative real-time operation of a client partand a server part of a client-server real-time computer programapplication over a computer network, the client and server parts beingadapted with a data exchange interface to a standard multimedia computercall control and communication program, characterised in invoking aclient part of a client-server real-time computer program application,invoking a client call control part of a standard multimedia computercall control and communication program, invoking a server part of said aclient-server real-time computer program application, invoking a servercall control part of said standard multimedia computer call control andcommunication program, and effecting a multimedia call from said clientcall control part to said server call control part, thereby establishinga real-time communication link between the client part of saidclient-server real-time computer program application and the server partof said client-server real-time computer program application.
 10. Amethod of establishing and running co-operative real-time operation of aclient part and a server part of a client-server real-time computerprogram application over a computer network, the client and server partsbeing adapted with a data exchange interface to a standard multimediacomputer call control and communication program, characterised in:invoking a client part of a client-server real-time computer programapplication, invoking a client call control part of a standardmultimedia computer call control and communication program, invoking aserver part of said a client-server real-time computer programapplication, invoking a server call control part of said standardmultimedia computer call control and communication program,communicating a setup message from said client call control part to saidserver call control part, communicating an accept message from saidserver call control part to said client call control part, communicatinga media suggestion and control receiver address message from said clientcall control part to said server call control part, communicating amedia accept and data destination message from said server call controlpart to said client call control part, communicating a media suggestionand control receiver address message from said client call control partto said server call control part, communicating a media accept and datadestination message from said server call control part to said clientcall control part, communicating a control message, as required by saidapplication program server part, from said application program serverpart to said application program client part, and communicating data, asspecified by said control message, from said application program clientpart to said application program server part.
 11. The method of claim10, characterised in that communicating the control message and the datamessage, respectively, is effected by direct message communicationbetween said application program client part and said applicationprogram server part.
 12. The method of claim 10, characterised in thatcommunicating the control message and the data message between saidapplication program client part and said application program serverpart, respectively, is effected by communicating said messages via saidclient call control part and said server call control part.
 13. Themethod of claims 9-12, characterised in that said standard multimediacomputer call control and communication program operates according toH.323 or SIP.
 14. The method of claims 9-13, characterised in that saidclient part of a client-server real-time computer program applicationand said client call control part of said standard multimedia computercall control and communication program operate on a first computerplatform, and that said server part of said a client-server real-timecomputer program application and said server call control part of saidstandard multimedia computer call control communication program operateon another computer platform.